Thanks for the submission @gdellis!

The custom provisioner means we're going to have do do a bit more thorough of a review.

We may be a bit slow to get to that deeper review, so we appreciate your patience!

In the meantime, a few things to chip away on/consider:

Provisioning approach
Using -p with --non-interactive is a reasonable v1 fit for shell plugins: the user is already at the terminal and unlocks 1Password first, and VeraCrypt documents -p even though it prefers --stdin for unattended scripting. I wouldn't block merge on switching to --stdin alone — that likely needs SDK/runtime stdin support anyway — but please add a brief comment in the provisioner noting why -p was chosen (no documented env-var path; attended single-user use).

Config-file importer (blocker)
Please remove TryVeraCryptConfigFile() — it registers ~/.VeraCrypt/Config but the callback is empty, and VeraCrypt does not store volume passwords on disk in config files (only preferences/favorites). If you want file-based import later, keyfiles (-k) would be a separate credential type, not a password importer.

Auth gating (blocker)
NeedsAuth should also skip commands that don't need a volume password — e.g. --list / -l, --version, and unmount (-u / --dismount) — not just help/version flags.

Import env var (minor)
VERACRYPT_PASSWORD is fine for import as a script convention, but it isn't a VeraCrypt CLI env var — worth a one-line note in the credential description so importers know it's import-only.

Cheers,
Scott